[レポート] Rancher Meetup Tokyo #18(モニタリングについて語ろう会)  #rancherjp

[レポート] Rancher Meetup Tokyo #18(モニタリングについて語ろう会) #rancherjp

Clock Icon2019.03.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは 園部です。

今回は、3月19日に開催されました Rancher Meetup Tokyo #18(モニタリングについて語ろう会) へ参加させていただいたレポートとなります。

Rancherとは?

Rancher は OSS と商用版で提供されるコンテナー環境構築・運用プラットフォームです。 Rancher の特徴は、Kubernetes コンテナオーケストレータ自体もデプロイし、その機能を利用した 効率的なコンテナインフラの構築・管理運用が可能なことです。 また、Active Directory 連携や監査ログ機能などにより本格的なエンタープライズ向けプラットフォームとして世界で導入実績を重ねています。 (引用:イベントサイト)

イベント開催概要

Kubernetesについて盛り上がりはどんどん増しつつあります。 米国ではKubernetesのスキルを持っていることが2019年時点では、もっとも転職に有利に働くといった調査結果もあり (Kuberenetesのスキルは、いま飛び抜けて米国の転職で有利。米Dice&米Indeed)、 Kuberenetesの人気はますます高まりつつあります。

しかし、本番運用まで含めるとKubernetesのスキルだけではくその周辺スキルも必要になってきます。 今回はその中から特に重要となる"監視・モニタリング"に焦点を絞って解説したいと思います。 (引用:イベントサイト)

Monitoring of Rancher(@cyberblack28 )

自己紹介

1. Basic Monitoring

  • ClusterやNodeなどのダッシュボードが提供

2. Alerts&Notifiers

  • 連携・通知先の設定するだけで利用が可能
  • 連携先として、Slack, Email, Webhook などに対応
  • コンテナに関するアラートとして、デフォルトで、etcd, kube componetns, event, node にも対応予定(v2.2.0-rc6)
  • Memoryは、デフォルトでは利用不可、Prometheusと連携することで利用可能になる予定(v2.2.0-rc6)
  • 他にもメトリクスを追加して、Alert 設定が可能
  • Alert は、exepresion がNEWサービス(Prometheus連携)で、GUIから簡単に設定可能

3. Basic Logging

  • エンドポイント設定を行うことで、多様なサービス(ElasticSearch, spluck, Kafka, Syslog, Fluentd)との連携が可能

4. Monitoring & Logging Catalog

  • 各プロダクトのカタログは用意されている(Grafana,、Prometheus、Datadog、ElasticSearch、Fluentdなど)
  • 要件に合わせて、任意のカタログをデプロイしていくのがRancherの良いところ

5. Rancher's New Multi tenant Prometheus support

  • Rancher 2.2 系列で、Prometheus がカタログからデプロイ出来るようになるため、簡単に構築が可能
  • Webinar で発表
  • 構築デモ(資料ベース)

6. Multi-Cluster Apps

7. Information

Cloud Native Tokyo #01(4/10)

Cloud Native Tokyo #01

k3s

submariner

所感

  • Rancher 2.2 系の新しいバージョンがリリース予定
  • Rancher 自体は、簡単な操作(GUI)で、デプロイや管理が可能
  • コンテナ管理から多様な環境(マルチクラウド、マルチクラスター)の管理へ進んでいる印象
  • k3s や submariner などユニークなものがある

Sysdig クラウドネイティブ インテリジェンス プラットフォームのご紹介(@takao3)

Sysdigとは?

会社紹介

  • 起業者は、Wireshark の共同創作者
  • 情報はまず全部集めてしまうという発想が強い
  • 昨年、Sysdig Japan 合同会社
  • 商用製品とOSSを取り扱っている
  • Sysdig Monitor, Sysdig Secure, Sysdig Inspect, Falco など

管理対象をめぐる状況

  • コンテナやマイクロサービスによって、どんどん複雑化が促進

Sysdig によるコンテナ管理

(引用:https://sysdig.com/)

  • オンプレ版とSaaS版がある
  • Sysdig バックエンドに情報(システムコール)を送理、各種サービスを提供

  • Sysdig エージェント経由でシステムコールをバックエンドへ収集
  • システムコールで収集しているので情報の粒度が細かい

  • 各ホストではなくサービス視点で表現

Sysdig Monitor Alert

  • Alertのタイプとして以下を提供
  • メトリクスベース
  • イベントベース
  • アノマリベース(時系列での異常検知)
  • pod ベース
  • テンプレートも用意

Sysdig inspect

  • ダッシュボード、分析ツール
  • 無料ローカル版もある

Sysdig セキュア

  • Sysdig MonitorもSysdig Secure も同じSysdig バックエンドに接続しており、UI や提供サービスが異なる
  • システムキャプチャを取得
  • システムコールを追うことで詳細な原因の追究が可能
  • OS上でのコマンドは全て管理
  • Compliance 機能
  • 詳細なポリシ設定が可能
  • Falco ルールも用意
  • CIS ベンチマーク 診断の実行も可能
  • コンテナイメージスキャンも可能

トライアル&チュートリアル

  • 2週間利用可能
  • 発表者のLinkedin にチュートリアルを用意 Linkedin

所感

  • コンテナ環境に対して、詳細なモニタリングが可能
  • 情報量が多そうな点でのコストやパフォーマンスに関しての懸念される場合は、事前に自分たちのシステムに置き換えて検討が必要

監視 入門 - マイクロサービス時代における監視設計 - (@songmu)

監視 入門 ~ マイクロサービス時代の監視設計

自己紹介

監視とは

監視とテスト

  • 奧一穂さんの名言「監視とは継続的なテストである」
  • 開発者がテストを書くことも一般化したが、監視はまだまだ専門的と思われている
  • モニタリングの重要性の向上(マイクロサービスアーキテクチャ)
  • やっていくしかない(みたいなことが書いてある)
  • Webサービスへの要求の向上
  • リアルタイム性
  • 監視からは逃れらない
  • 「監視とはシステムに対する高速健康診断」 by 発表者
  • 監視のコード化 されているため、アプリケーションエンジニアにも扱える領域
  • healthエンドポイントパターン
  • 「入門 監視」で命名
  • /health にアクセスすることで監視用データをレスポンスさせて内容を監視(JSONとか)
  • Health Check Reponse Format for HTTP APIs
  • https://github.com/inadarei/rfc-healthcheck
  • https://tools.ietf.org/html/draft-inadarei-api-health-check-02
  • Open Metrics https://openmetrics.io/
  • 標準化が検討されている

開発者と監視

  • 「テスト駆動開発は、プログラミング中の不安をコントロールする手法だ」
  • テスト駆動開発
  • 開発者こそ監視するべき
  • アプリケーション開発者でこそわかる監視項目があるはず

マイクロサービス時代における監視設計

  • アプリケーションとミドルウェアの境界は曖昧になる
  • Four Golden Signals(in SRE Book)
  • Latency
  • Traffic
  • Errors
  • Saturation
  • Use Method(システム・パフォーマンス本)
  • http://www.brendangregg.com/usemethod.html
  • 詳解 システム・パフォーマンス
  • 内部の状態に着目(ブラックボックス)
  • Utilization
  • Saturation
  • Errors
  • RED Method
  • Monitoring Microservices
  • 外部からの振る舞いに着目(ホワイトボックス)
  • Rate
  • Errors
  • Duration
  • USEは内部、REDは外部から視点で、補完しあうもの
  • 監視パラダイムの変遷
  • チェック監視
  • メトリクス監視
  • Observability

Mackerel コンテナエージェント

  • リリースされたコンテナエージェントの紹介
  • サイドカー設計
  • マイクロホスト課金
  • サービスメッシュ、Prometheusと連携も検討

ケーススタディ

所感

  • 対象となるシステム環境(アーキテクチャ・コード管理・チーム垣根)の変遷に対して、監視も着実にかわっていることを実感しました。
  • 監視設計に関する一般化は重要だと個人的にも思います(システム担当 >>> インフラ担当 >>> 運用担当 ではもう最適な監視は設計できないはず)

Feedback from Cloud Native Deep Dive - みんなのモニタリングお悩み共有(@jacopen)

Cloud Native Deep Dive とは?

  • 色々なテーマに対して全員参加型のディスカッション
  • 事前にアンケート回答の上で、参加
  • 前回、Monitoring をテーマにした内容だったため共有
  • 他の開催テーマ:Manifest 管理, Service Mesh, Release Engineering, JKD 総集編
  • 正解ではなく、議論を行う場

Monitoring

  • Blackbox Monitoring と Whitebox Monitoring を分けて考えよう!
  • Black Box vs. White Box Monitoring: What You Need To Know
  • みんなの課題
  • どんなメトリクスを監視すればいいのか?
  • k8s のクラスタ管理者とアプリ開発者への通知切り分け
  • ロングタームのメトリクス管理方法・ダウンサンプリング方法
  • 外れ値対応
  • モニタリングのモニタリング
  • そもそもダッシュボードはいつ見る?
  • Monitoring 101 は読むべき

Logging

  • Logging = 課金
  • みんなの課題
  • Aggregator運用が辛い
  • ログ形式バラバラ問題
  • ログとメトリクスの横断的な検索

Alert

  • みんなの課題
  • 閾値の根拠は?
  • 誤検知・過剰なアラートへの対応
  • 閾値やアラートレベルの見直しはいつやる?
  • 通知先
  • オンコール担当は誰か
  • オンコール先任者・部門が必要か?
  • オンコールローテーション
  • 突発的なアラートへの対応による生産性の低下
  • アラートルールのコード化はどうやるか?
  • 通知すべきメトリクスのベストプラクティスはあるのか?

共通課題

  • コード化・自動化
  • 対応する人・組織・ロール
  • OSSか商用製品かManaged Serviceか?

宣伝

所感

  • 「みんなの課題」ではあるあると共感した方も多かったのではないかと思います。
  • LT のため、時間の都合があったようで、ハイライトではありましたが、Cloud Native Deep Dive の濃密さを感じます。
  • Monitoring 101 はしっかり読んでおこうと思います。

その他

本編が始まる前に、DirectPoll によるアンケート(参加者のロール、Docker 利用状況、k8s 利用状況)が実施されました。こちらは、面白かったです。 アイスブレイクに最適だと思いました。

また翌日に、EKSでのRancher の記事(Managing Amazon EKS Clusters with Rancher )が掲載されており、タイムリーさを感じました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.